In `@apps/ensindexer/src/lib/indexing-status-builder/chain-block-refs.ts`:
- Around line 14-28: The null-check on the result of publicClient.getBlock in
fetchBlockRef is dead code because viem throws on missing blocks; remove the
unreachable if (!block) branch and instead ensure you never pass null into
bigIntToNumber by asserting or guarding block.number and block.timestamp before
calling bigIntToNumber (e.g., use non-null assertions or explicit checks) so
deserializeBlockRef receives valid numbers; keep the call to
publicClient.getBlock as-is and update fetchBlockRef to rely on viem errors
while preventing block.number/block.timestamp from being null when calling
bigIntToNumber/deserializeBlockRef.
- Around line 108-110: The catch block currently swallows the original exception
and throws a generic Error; update it to preserve the original error as the
cause so debugging info is retained: capture the caught error (e.g., catch
(err)) and rethrow using the Error cause option or include err.message in the
new Error (for example: throw new Error(`Could not get BlockRefs for chain
${chainId}`, { cause: err }) ), referencing the catch in chain-block-refs.ts
where the current throw occurs and the chainId variable used in the message.
- Around line 64-111: The loop over chainIds is performing RPCs serially; change
it to run per-chain work in parallel by mapping chainIds to an array of async
tasks and awaiting Promise.all (or Promise.allSettled with error aggregation).
For each chainId task, read chainsConfigBlockrange, publicClients, and
chainsIndexingMetrics, compute startBlock/endBlock/backfillEndBlock, call
fetchBlockRef for the three refs, construct the ChainBlockRefs object, and
return [chainId, chainBlockRef]; after Promise.all resolve, populate
chainsBlockRefs from the results (or throw a combined error if any task failed).
Ensure you keep the same validation checks
(startBlock/publicClient/indexingMetrics/historicalTotalBlocks) inside each task
and include chainId in any thrown errors to aid debugging.

In
`@apps/ensindexer/src/lib/indexing-status-builder/chain-indexing-status-snapshot.ts`:
- Around line 46-94: The Queued branch (when
isBlockRefEqualTo(chainBlockRefs.config.startBlock, checkpointBlock) is true)
can mask contradictory states if chainIndexingMetrics.indexingCompleted or
indexingRealtime are also true; update the queued branch in
chain-indexing-status-snapshot to emit a defensive warning (e.g., logger.warn)
including chainId, checkpointBlock and which metric(s) are set before returning
the Queued snapshot so these inconsistencies are visible in logs; keep the
existing return value (validateChainIndexingStatusSnapshot with
ChainIndexingStatusIds.Queued) but do not change downstream logic.

In
`@apps/ensindexer/src/lib/indexing-status-builder/omnichain-indexing-status-snapshot.ts`:
- Around line 33-34: The code currently calls getOmnichainIndexingStatus(chains)
and then calls getOmnichainIndexingCursor(chains), but
getOmnichainIndexingCursor internally recomputes getOmnichainIndexingStatus —
avoid the double computation by computing omnichainStatus once and passing it
into the cursor helper (or refactor getOmnichainIndexingCursor to accept an
already-computed status): change the call to something like
getOmnichainIndexingCursor(chains, omnichainStatus) and update the helper
function signature (and any other call sites) so it uses the provided
omnichainStatus instead of calling getOmnichainIndexingStatus again; ensure
tests/usage are updated accordingly.
- Around line 36-67: The switch on omnichainStatus (in
omnichain-indexing-status-snapshot.ts) is missing a default/exhaustiveness guard
so new OmnichainIndexingStatusIds variants could cause an undefined return; add
a final default that throws an informative error (or call an assertUnreachable
utility) including the omnichainStatus value to ensure exhaustiveness and
preserve the function's return contract for
validateOmnichainIndexingStatusSnapshot callers.

In
`@apps/ensindexer/src/lib/indexing-status-builder/validate/chain-indexing-status-snapshot.ts`:
- Around line 1-7: validateChainIndexingStatusSnapshot currently returns its
input without checks; replace the no-op with real validation of the
discriminated union ChainIndexingStatusSnapshot by switching on the discriminant
(the variant tag) and asserting each variant's required fields and types (e.g.,
Queued, Backfill, Following, Completed-specific invariants such as required
numeric offsets, timestamps, or nullable fields), throwing a descriptive Error
on failure; if you cannot implement full checks now, replace the body with a
clear TODO comment mentioning validateChainIndexingStatusSnapshot and
short-circuit with a runtime assertion (e.g., throw new Error("TODO:
validateChainIndexingStatusSnapshot not implemented")) so callers don't get
silent false confidence.

In
`@apps/ensindexer/src/lib/indexing-status-builder/validate/omnichain-indexing-status-snapshot.ts`:
- Around line 3-7: The current validateOmnichainIndexingStatusSnapshot function
is a no-op leaving unsafe `as` casts unchecked; update
validateOmnichainIndexingStatusSnapshot to add a TODO with a tracking
ticket/reference and implement minimal runtime guards: assert the top-level
discriminant (omnichainStatus) and switch over its known cases (use an
assertNever fallback) and for each entry validate the per-chain `chainStatus`
discriminant and expected shape (e.g., verify Maps contain expected value types)
so the identity cast is safe at runtime; reference the function name
validateOmnichainIndexingStatusSnapshot, the omnichainStatus discriminant,
chainStatus, and use an assertNever-style helper for unhandled cases.

In `@packages/ponder-sdk/src/blocks.ts`:
- Around line 33-51: The ordering function isBlockRefBefore currently requires
both number and timestamp to be strictly less which misorders blocks when
timestamps are equal; change isBlockRefBefore to compare only blockA.number <
blockB.number (use block number as canonical ordering), update
isBlockRefBeforeOrEqualTo to rely on that (or number ===), and optionally add a
separate validation/assertion (e.g., inside isBlockRefEqualTo or a new
validateBlockRefConsistency helper) to log or throw when block numbers are equal
but timestamps differ so timestamp mismatches are surfaced without affecting
ordering.
- Around line 74-94: BlockrangeWithStartBlock is unused internally but is
re-exported publicly via index.ts; mark it as deprecated to avoid breaking
consumers now and communicate planned removal in the next major release. Add a
JSDoc `@deprecated` tag to the BlockrangeWithStartBlock interface with a short
message like "Unused internally; scheduled for removal in next major release"
(leave the export in index.ts unchanged so consumers keep compatibility) and
update any public docs/changelog to note the deprecation.

In `@apps/ensindexer/src/lib/indexing-status-builder/chain-block-refs.ts`:
- Around line 90-96: The code currently only checks that
indexingMetrics.backfillSyncBlocksTotal is a number; update validation so
historicalTotalBlocks (the value assigned from
indexingMetrics.backfillSyncBlocksTotal) is a positive integer (use
Number.isInteger and > 0) before computing backfillEndBlock = startBlock +
historicalTotalBlocks - 1; if the check fails throw an Error that includes
chainId and the invalid value to make the misconfiguration obvious.
- Around line 31-33: The catch block in chain-block-refs.ts currently creates a
new Error with the message but drops the original error; update the throw to
preserve the original error via the Error cause option (i.e., throw new
Error(`Failed to fetch block ref for block number ${blockNumber}:
${errorMessage}`, { cause: error })) so the original stack and identity are
retained for proper error chaining; keep the existing errorMessage logic (error
instanceof Error ? error.message : "Unknown error") and pass the original error
variable as the cause when constructing the new Error.

In
`@apps/ensindexer/src/lib/indexing-status-builder/corss-chain-indexing-status-snapshot.ts`:
- Around line 1-6: The file name has a typo
("corss-chain-indexing-status-snapshot.ts"); rename it to
"cross-chain-indexing-status-snapshot.ts" and update every import/reference that
points to the old name so modules can resolve correctly; check for usages
referencing CrossChainIndexingStatusSnapshotOmnichain,
CrossChainIndexingStrategyIds, and OmnichainIndexingStatusSnapshot and adjust
their import paths to the new file name, then run TypeScript/IDE imports fix to
ensure no broken references remain.

In `@packages/ponder-sdk/src/index.ts`:
- Around line 6-7: The top-level exports of numbers and time in
packages/ponder-sdk/src/index.ts surface a zod/v4 dependency via exported
validators (symbols: numbers, time, and zod) which may violate the Layer 1
constraint; decide whether zod is permitted and then either (A) keep the exports
but document/accept the zod dependency, or (B) refactor so zod types/validators
are internal only: remove re-exports from the public index.ts and instead export
plain JS/TS types or helper functions (or convert validators to simple runtime
checks) so no zod symbols leak from numbers.ts/time.ts; update the module
exports in index.ts and adjust numbers.ts/time.ts to either internalize zod
imports or expose non-zod-safe public APIs accordingly.